Business Analyst Community & Resources | Modern Analyst

Satisfy Requirements with Continuous End User Involvement

Mendix.com — Thu, 17 Feb 2011 12:49:00 GMT

Perhaps the most important facet of agile software development is its innate ability to satisfy user requirements better, more accurately, more consistently, than what is considered ‘traditional’ software development. Where ‘traditional’ software development begs the user for all necessary information upfront and then reluctantly for feedback at the end of a project, agile development never lets the user out of sight.

This one differentiation separates traditional and nontraditional, slow and fast, waterfall and agile, 50% requirements satisfied and 100% requirements satisfied. The iterative nature of agile development forces engineers to go back to the user regularly, but more importantly, forces them to think of the user continuously. This interaction, and its psychological properties, is at the discretion of the platform employed.

While there are thousands of sales people that will graciously explain why one platform is more worthy than another, I will for once stay software agnostic and comment solely on the significance of the decision. As with any methodology, one platform may lend itself more appropriately to agile development (and the notion of continuous user involvement).

The stand ups, stories, and acceptance tests keep engineers in cadence with each other and the end user they aim to satisfy. Those very same end users that willingly provide their continuous feedback and involvement are under the direction of the decision maker responsible for your project. Your feedback loop with your end user is therefore their feedback loop with their supervisor.

So as the gears of your agile team continue to turn, they propel the internal gears of your client’s team, creating a centralized dependency on the accuracy, clarity, and knowledge of your end user. This person has a very good reason to be involved in your project, as you have a very good reason to keep them involved. The end result: software that satisfies the requirements of its users.

In office dialect: technology that satisfies the needs of the business.

By no means am I original in saying that the software development world has accepted agile development as a recognized response to decades of wasted time, sunken investments and fruitless skills. History (as unpredictable as it can be) tells us that steady adoption of new, speedier methodologies in young, innovative companies precedes its penetration into organizations of more portly proportions. In effect, the companies who adopt agile last are those who need it most.

Coaching Football and Agile Applications: It’s Game Time

Mendix.com — Tue, 04 Jan 2011 13:53:00 GMT

Many business analysts and heads of industry find themselves in compromising situations. Their team is down and they can’t seem to move the business properly towards the goal. It seems your competitor across the field is always one step ahead, providing results and fan [customer] satisfaction. But how did they do it and why can’t you come back?

Game Planning

This powerful opponent of yours has come up with a great game plan. The product they use – whether it’s the right gloves, cleats, breathable uniforms, etc. in sports – or a better system from order receipt, to entry, to delivery in business – is fundamentally better… but why? Did this opponent read the weather forecast and plan for adverse conditions? Are they just more talented with players or products that are just better suited for the game? Do they have systems in place that allow for adjustment depending on what is working and what isn’t?

Adjustments

Many of us head into planning a certain way based on what we have and who we’re up against. Let’s say you’re going into the match against the #1 passing team in the league. You spent the whole week practicing your nickel pass defense with plans to stop their attack. But what happens when you get into the game and you realize that their third string ball carrier is a beast? He’s tearing your defense up all over the field. Do you continue to play the pass even though they are running on every single down? No, you need to adjust your game to play with them.

In business it’s the same way, let’s take the classic example of the traditional video store. For years it was all about having the largest selection, being in a convenient location, and providing rentals at a reasonable price. In comes a new team with a new strategy, let the customer handle every transaction online without ever having to leave their house. Some of the traditional storefronts adjusted, downsizing locations and adding a similar online offering to their large customer base.

How does this all tie together?

Much like the coach that is able to switch his defense to line up eight in the box against the team running all over them, the large video store needs to be able to position itself against a competitor’s strategy. But what if this company doesn’t have the ability modify its business strategy? What if they need a complete overhaul of its application infrastructure to do so? This is going to cost the business large amounts of time and money. The money will absolutely have to be spent if the company wants to stay in the game for the long haul. But what about the time it takes to develop the application?

Many of the mid-sized video providers didn’t have the brand, size, nor money to bridge them into this new age of video rental. By the time they were able to come to market with a suitable offering, they were competing against the other small companies who also didn’t adapt fast enough. Do yourself a favor and build your original application on a platform that is agile and can change with your business needs. That’s the moral of this story – agility wins.

The Agile Application Assassin

Mendix.com — Tue, 16 Nov 2010 13:51:00 GMT

You know, it’s the coolest nickname I’ve ever received - but it almost sounds negative. I mean am I going in and assassinating your application? No, I go in and make the changes you request and re-deploy your application. So why give me that nickname?

Pretty easy I guess, when I’m operating strictly as the implementer of a solution, I am able to focus on functionality and how I can improve it. Typically during meetings I write all the customer requested changes down and begin implementing them once we move past that section of the conversation.

Recently during a phone call with a client I was able to test drive the new functionality I built for them in the day prior. Once we went over it all and they gave me their feedback I went to work to make it happen. The online meeting switched to talk about other status reports for members outside of our organization.

By the time they were done I had made the necessary changes, re-deployed their model, and was able to have a second round of test driving during the same meeting. The customer was astonished to see these changes happen so quickly that they dubbed me the “Application Assassin”. “Seriously, how did you do that so fast? Did you already have a different version in mind?” No, I just have the Magic of Mendix. Drag, drop, double click, and deploy…….it’s magic! Maybe the nickname should be the “Application Magician”.

Sometimes I’m truly amazed by how quick it is to write and change full applications so fast. But I guess when it’s all visual and no coding it’s easy. Consider this story the next time your business needs have you in a strait jacket wrapped in chains. You may want to have a magician (we still prefer Business Engineer) on your side. That way when the realization is made that your approach should be different, you will be ready.

Enter the Business Engineer: Part 2

Mendix.com — Tue, 19 Oct 2010 19:36:00 GMT

In a previous post regarding the emergence of the Business Engineer, I discussed the Who, What and Why of this new type of human capital. At Mendix, we see them growing in numbers, most likely due to the nature of our software. If you’re going to give business analysts the ability to develop software, or developers the ability to communicate business – you’re going to see doors open and walls collapse on either side of the business-IT equation.

The BA

In order to figure out exactly where BE’s come from, so that we can harness their powers for the greater good of business agility, we’ll have to know more about their closest relative – the BA. According to The International Institute of Business Analysis, the role of a business analyst involves: “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.”

Well isn’t that something. All of those tasks and techniques are funneled down into a recommended solution and passed along to the technical wizards who turn requirements into reality. I’ve always wondered whether the less-than-technical BAs wish they could, perhaps just once, finish the job and deploy an application. Perhaps they’d hate to deal with code, I’m not sure. What I am sure of, however, is that business engineers dream about models (business-models, pervert!) and how great it would be if they could get requirements and deliver solutions, on their own.

The BE

Call it selfish; call it futuristic; you can even call it a pie in the sky. With the emergence of the business engineer, demand for agile software development, visual modeling tools and a revamped SDLC is truly explosive. Based on the definition above, the BE is not really related at all to who we now know as the business analyst. Though I mean not to offend nor aggravate business analysts or software developers, I must assume that they see the astronomies of their value propositions colliding.

So then, if the business analyst recommends a solution, it must be the business engineer who implements it. And if the business analyst plans the solution, the business engineer deploys it. I may even go as far as to say that business analysts identify the problem, where business engineers solve it. This fine, yet drastic and seemingly impossible, line – is growing in organizations everywhere.

What’s Next

As I mentioned in part one of this series of posts, the ambiguity of the business engineer is becoming more believable with every Mendix user. What was once called impossible by technologists is now championed as magic by audiences of our ‘proof’ of concepts, and we’re betting will one day be considered the norm in enterprise software development. In the meantime, collaboration between business and IT may remain segregated by occupational obstacles inherent to aging technologies and ancient practices.

The current generation of business and technology students is likely to pave the way for career paths in business engineering. Courses in business engineering will be taught by today’s business engineers, and until then, these heroes of enterprise software can only enlighten their organizations with a glimpse into the future of business agility.

Enter the Business Engineer

Mendix.com — Tue, 05 Oct 2010 13:53:00 GMT

At Mendix, we find that our customers appoint a particular kind of person to work with our products. Sometimes they’re from IT, sometimes they’re a business analyst or project manager – in any case, they practice the skills of both fields. Times are changing, departmental lines are blurring, and a new breed of business superhero has risen: the BE.

The ‘Business Engineer’ – who are they, what do they do, and why you want to know them.

Who

Until now, these men and women of myth have appeared under the guise of your organizational boundaries – half business and half IT. As champions of business modeling, they dance between the ranks of geeks and suits in companies everywhere, aptly increasing business agility at every collaborative junction. With a flash drive dangling from their sports car keychain and first place positions in both Online Poker and Fantasy Baseball, they are what we believe to be the future of the modern business analyst. In this series of blog posts, we attempt to uncover the true nature of this evolved employee…

What

The title of ‘business engineer’ is not completely novel, as it has been used in the past to describe a role similar to that of a business development manager. Under a new light of enterprise software modeling, this term refers to the business analyst on technical steroids – or the IT whiz with a knack for client relations. These skills, once segregated at a basic level of undergraduate education, have merged into a hybrid force of human capital with more creative power than either part could ever fathom.

These collaborative powers can push companies into unchartered profits, as they attribute to the resiliency of a company’s technology. Agility, as readers of this blog know, affords an organization the ability to change with its business environment. The more easily technological change can occur, the faster and more decisive an organization becomes. Charles Darwin says it best: “In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.”

The business engineer is not a mythical entity – they may even be sitting in the room as you read this post. Finding them and harnessing their abilities should be a primary goal of any manager. In terms of organizational behavior, they are the ‘central connector.’ In terms of organizational culture, they are the ‘go-to guy.’ And in terms of business agility, they are the binding force between business users and technical experts that have never been able to see eye to eye.

Why

The reasons why you’d want business engineers in your company are significant. They make the technology that your company uses easier to use, more intuitive, and they do so faster and with minimal adversity. With the adoption of visual business modeling, and agile development methodologies, these unsung heroes of the enterprise era are here to stay. Do you know the business engineer at your organization? If not, it just might be you.

Telecom Companies are ready for the Cloud

Mendix.com — Mon, 20 Sep 2010 16:26:00 GMT

Telecommunications companies are looking to cloud computing to clean up inefficient processes throughout the sales channel. The products and services in this industry change so often that these companies have become more competitive than ever, with continuously shrinking margins. Flexible front end solutions bring agility to the sales process, providing a future proof solution to front office and extended enterprise portals. As the masses continue to frenzy over new data pumping smartphones, internet connected television, and television connected internet – these organizations continue to face seemingly unparalleled challenges in business agility.

So begins the first of a series of blog posts titled “Telecom Channel Portals 2.0” in which I plan to discuss a few interesting ways that telecommunications companies will benefit in a new age of software. Software as a service is fundamentally changing the cost structure of information technology, and industries in which competition for profits is the fiercest will ultimately be the earliest adopters. The following three applications are common areas of interest for telecommunications companies looking to enter the Saas realm.

1. Marketing Portals

When products and services change as often as they do in the telecommunications industry, disseminating that knowledge throughout agent channels (partners and direct marketing/sales people) is extremely important. Marketing portals give agents and resellers access to up-to-date information from any browser. Sales in this industry are driven by intensive campaigns for which supporting marketing materials and product/service catalogs need to be readily available. There is no better way to manage and to provide this information to agents and resellers than via an online portal.

2. Quoting and Order Entry

Online portals for quoting and order entry increase direct business value for telecom providers and resellers. On either side of the equation, stakeholders get data faster and more accurately, which speeds up customer acquisition while minimizing costs. Telecom providers become more attractive to partners, and the list of benefits goes on and on. By making it quick and simple for the sales channel to give and take information from their provider, business agility is greatly improved.

3. Commission Automation

Online portals can go much further than displaying and collecting information. By including logic into an application, the functionality and time saving capabilities become endless. All too often, we see gigantic excel spreadsheets used for finance-based processes such as tracking commission payments. By automating this process, time is saved, errors are avoided, and transparency is increased. Online portals can be automated and customized for recurring commission structures based on the type of partner and product/services being sold.

These are just three ways that online portals are changing the way information is managed in the telecommunications industry. The reliance on information is so great that adopting cloud computing is almost inevitable. Keep an eye out for more “Telecom Channel Portals 2.0” posts on the Business Agility Blog.

Mendioms for Business Analysts

Mendix.com — Wed, 01 Sep 2010 13:04:00 GMT

A Mendiom is an idiom with a Mendix twist. This is the first of a series of posts with Mendioms for different types of people. This week, we have chosen a few of our favorite Mendioms for business analysts.

Business analysts are an important part of an organization’s business agility. By having the responsibility of communicating between business and IT, business analysts can greatly reduce time to market of new solutions by using agile development methods. In an effort to both inform and entertain, here are a few slides for my business analyst readers.

Visual Modeling – Stopping IT Failure at the Root of the Cause

Mendix.com — Tue, 17 Aug 2010 12:40:00 GMT

I came across this slideshow from CIO Insight a few weeks ago. The aggressive-looking deck attempts to explain why IT projects fail. I’m always a bit weary of headlines that seem this simplistic, but who knows – maybe they thought up some new ways to blow a project that millions of us hadn’t already avoided, accomplished, or observed. Better yet, wouldn’t it be something if we finally figured out how to diminish the “63 billion dollars” worth of failed projects in the US?

Clicking through the deck, I realized that a majority these reasons are somewhat interconnected. It’s not just lack of detailed requirements, lack of user involvement, scope creep, bad scoping, poor testing, or lack of executive support. An innate segregation between the business people who use the product, the IT people who build the product, and the business analysts who dance in between – is the root cause of most of these problems.

Enhance Collaboration, Improve Requirements

The logical solution to these failure-inducing practices is visual modeling. By using visual models, both sides of the IT-Business equation have a valuable representation of what the IT project will encompass. By using this method of collaboration, requirements become more accurate. Business people can visualize the processes that the software will benefit, and IT people have a more functional way of communicating their solution.

The Immediate Feedback Loop

If we take one step further into the initial requirements analysis, these visual models can be deployed as applications for an immediate look into future checkpoints in the project. Imagine the following scenario:

Business Analyst: “So the data from your current ERP system will be aggregated and validated in the new system, which will then report directly to their corresponding contacts from your CRM.”
Client: “Right…”
Business Analyst: “Ok, well this is the model with data flows – and this is what the application will look like to the contact in the CRM system.”
Client: “Wait, that’s not all the data they’re going to need. What about integrating the grant management database?”

[A few clicks, a new form, and deploy.]

Business Analyst: “Okay, so now the window shows the corresponding grants for each contact as well.”

Isn’t immediate feedback fun!? It’s a dream for business analysts that has only recently become a reality (in the Mendix Business Modeler, that is). Mendix users never come close to failing a project because clients know exactly what they’re getting and developers know exactly what is needed. So why are so many IT projects failing? The right tools are out there, it’s only a matter of time before they are discovered.

The Mendix Community Fully Embraces Open Source

Mendix.com — Fri, 13 Aug 2010 17:03:00 GMT

The idea of open source information gathering has been utilized in the scientific community for centuries. It is no secret that sharing information created by communities of experts provides the most productive basis for advancement, regardless of subject matter or field of study. Business engineers developing on the Mendix platform utilize our own MX forum and AppStore to discuss, learn, and share their thoughts for the betterment of their applications. Our Research and Development team use the forum to make the Business Agility Suite better for our users. It is, at its very heart, a cyclical philosophy that mutually benefits those who learn and those who create.

Again, the advocates for open source are vast and ever growing. The following anecdotes aim to portray our wholehearted belief in using open source in the advancement of our technology.

1. Sharing is Caring

The Mendix AppStore is a fantastic example of our own community embracing open source. Most of the content in our AppStore is open source. Our partners have been busy creating interesting software modules that can save other developers time and money. In return, they will have access to other developers applications, widgets, and themes. The AppStore is available to our partners and users now, but will be open to the public soon. Developers also share the ability to make the contents of our AppStore better, as discussed in the following…

2. Concealed knowledge is static knowledge

A century ago, intellectual property laws were all the rage. In many industries, they still serve a valid purpose that may very well foster innovation. For instance, pharmaceutical research must remain concealed in order to protect the value creation that finances it. (Then again, Andrew Witty of GlaxoSmithKline, is placing his bets on open source research to find a vaccine for malaria.) In many cases, however, when knowledge is concealed from the public eye, it remains static and unchallenged, and therefore compromised.

The often overlooked side of what makes an open source philosophy valuable is in the review of content. While creation of content by the masses demonstrates the initial benefit of open source, the ability to have innumerable judges critiquing that very content is equally valuable. Shared content is validated by peers, rather than say, the reputation of its creator. In fact, the MX Forum rates its users based on their contributions. This way, reputation is directly related to the reaction ones contributions receive.

3. Disseminating knowledge is just as important as creating it

It turns out that an open source philosophy contains within itself a similar relationship to that of the chicken and the egg. Which is more important: The supply of new knowledge, or the ability to communicate it? The Internet has given us the ability to communicate and create vast amounts of information simultaneously. Open source philosophy, as it has developed online, has become hugely more impactful as the Internet evolved into its current state. With more access to knowledge comes more knowledge, and with more knowledge comes more innovation. Again, a cyclical growth of intellect is fostered by open source.

My motivation for writing this post came about when our forum, the MX Forum, was featured on OSQA – The Open Source Question and Answer System – well, forum. This site is an interesting demonstration of open source philosophy, as it literally centralizes open source forums within its own open source forum. Since the team at Mendix applauds open source philosophy, we were happy to provide our forum to its visitors.

5 Steps to Improving your Career as a BA

Mendix.com — Tue, 03 Aug 2010 13:28:00 GMT

The community of business analysts in the United States and abroad is taking notice of their impact on the world economy. Not long ago, the idea of a business analyst was new – sitting on the border of technology and business, sharing lunch with both ‘geeks’ and ‘suits,’ and creating value with only the uncanny ability to collaborate between these corporate cultures. These collaborative colleagues will continue to develop alongside, and in between, new technology and new business. The growing popularity of agile methodologies and visual modeling software motivated me to put together this deck of five simple steps to a future focused business analyst.

Much of my research in the business analyst kingdom has led me to believe that the majority of these individuals would do more if they could. In other words, given the opportunity – a good business analyst would talk to the client, write the requirements, build – implement – and test the software, and then provide support to the client for years to come. (Ok, so maybe less credit is due – but you get the point.) Since this magical persona does not exist and may never exist, we can at least give them the tools to delve further into application development. Visual modeling - the ability to visually convey business processes and logic in a manner that both business and IT people can understand - is one such tool. Take it a step further, and allow these business analysts to deploy their models as a living, breathing, application – and you’ve turned a corner in business analyst evolution.

So, to the eager business analyst who wants to get ahead of the game:

Think Big.
Think Balanced.
Be Marketable.
Use Visuals.
And most of all: Think Agile.